Methods and systems for moving data objects

ABSTRACT

A method comprising selecting a data object from a first storage location; assigning an identifier (ID) to the data object; storing the ID in a transactional type lock object; determining whether the ID is stored successfully in the transactional type lock object, and upon a successful storage, storing the ID in a permanent type lock object; determining whether the ID is stored successfully in the permanent type lock object, and upon a successful storage, deleting the ID from the transactional type lock object; storing the data object at the second storage location; assigning the second storage location to the ID in the permanent type lock object; deleting the data object from the first storage location; and deleting the ID from the permanent type lock object after the respective data object assigned to that ID has been deleted from the first storage location.

This application is a national stage filing under 35 U.S.C. § 371 ofInternational Application No. PCT/EP2003/009828, filed on Sep. 4, 2003,which published in the English language, and claims the benefit ofpriority to U.S. Provisional Application Nos. 60/408,901, filed on Sep.9, 2002, 60/408,902, filed on Sep. 9, 2002, 60/408,903, filed on Sep. 9,2002, 60/408,905, filed on Sep. 9, 2002, 60/409,606, filed on Sep. 11,2002, and 60/409,593, filed on Sep. 11, 2002.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The technical field of this invention is in the area of electronic dataprocessing. More particularly, the invention relates to methods,computer program products and systems for data moving.

2. Description of the Related Art

Moving of data objects is well known to every user of a computer and isa standard procedure, which is routinely applied. A special applicationof moving data objects is the archiving process, by which data objectsare moved from a first to a second storage location for safety and/orperformance reasons. In enterprises, enterprise resource planningsoftware (ERP) applications are used to control or support businessprocesses and the management of the enterprise. ERP software is furtherused to manage company information of enterprises of various kinds inany field of technology by means of automatic data processing systemssuch as computers or computer systems. During the use of such software ahuge amount of data is usually created, which contains importantbusiness information and which has to be archived from time to time.

According to the state of the art (see Helmut Stefani, Datenarchivierungmit SAP, Galileo Press GmbH, Bonn 2002, ISBN 3-89842-212-7), archivingcan be performed automatically by archiving software tools, which can bepart of the ERP software. Such tools can consist of a writing module,which stores (writes) the data objects to be archived sequentially inarchive files, and a deleting module, which deletes the successfullyarchived data from the original data object base. The writing module canselect the data objects to be archived from the data base according tospecific criteria, e.g. the creation time of the data. It usually doesnot modify the original data objects or data base. The deleting modulestaggeredly reads the archive file sequentially and deletes the dataobjects found in the archive file from the original data base. Thisensures that only such data objects are deleted from the original database, which are readably stored in the archive file. The time for thearchiving procedure as a whole depends on the amount of data and variesfrom a few milliseconds to several hours or days. Consequently, there isin many cases a considerable time gap between writing the data into thearchive file and deleting the data from the original data base. Thistime gap can be a reason for the following problems:

As long as the data objects are still available in the originaldatabase, they can still be modified during the time gap. Because thedeleting program does not compare the archived data object and the dataobject to be deleted, such modifications can be lost. This has not onlythe consequence of the loss of the amended data, it can additionallyhave the consequence that certain business processes can not becompleted.

Another problem arises if several archiving processes run in parallel.In this scenario, that one data object can be archived several times,and is no longer unambiguously identifiable. This can have theconsequence that evaluations or statistical analysis, which use thearchive files, produce wrong results.

It is also possible that data objects in the original database are readby the writing module and are simultaneously modified by anothersoftware application. In such a case, the data can be transferred froman archiveable status to a non-archiveable status. As a result, dataobjects which are not archiveable are written into the archive file andare deleted from the original database. In effect, this can result in aloss of data.

Thus, there is a need for a method and/or data processing systemproviding a more efficient solution of the problems described above.

SUMMARY OF THE INVENTION

In accordance with one embodiment of the invention, as embodied andbroadly described herein, methods and systems consistent with theprinciples of the invention provide for moving data objects in acomputer system from a first storage location to a second storagelocation, comprising:

-   selecting one or more data objects from the first storage location;-   assigning at least one identifier (ID) of at least one type to each    of the selected data objects;-   storing the at least one ID in a lock object;-   storing a data object, the ID of which is contained in the lock    object, at the second storage location and assigning the second    storage location to the ID in the lock object;-   deleting the data object, the ID of which is contained in the lock    object, from the first storage location; and-   deleting the ID from the lock object after the step of deleting the    data object from the first storage location for the respective data    object assigned to that ID has been completed.

By using this method, software applications, which require access todata objects, can check by querying the lock object, whether the data tobe accessed are subject to a moving process or not. If yes, the accessto that data can be postponed until the moving is completed.

In accordance with another aspect of the invention, as embodied andbroadly described herein, methods and systems consistent with theprinciples of the invention provide a computer system for processingdata, comprising:

-   memory means for storing program instructions;-   input means for entering data;-   storage means for storing data;-   a processor responsive to program instructions; and-   program instructions adapted to carry out the method described    above.

The invention and its embodiments are further directed to a computerreadable medium and a carrier signal comprising instructions forprocessing data according to the inventive method and in itsembodiments.

One advantage of the invention and its embodiments is that the securityagainst data loss in data moving and archiving procedures may be greatlyimproved. This may avoid spending a lot of time and money for dataretrieval.

Additional objects and advantages of the invention and its embodimentswill be set forth in part in the description, or can be learned bypractice of the invention. Objects and advantages will be realized andattained by means of the elements and combinations particularly pointedout in the appended claims. Embodiments of the invention are disclosedin the detailed description section and in the dependent and appendedclaims as well.

It is understood that both the foregoing general description and thefollowing detailed description are exemplary and explanatory only andare not restrictive of the invention and its embodiments, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate examples of embodiments of theinvention and, together with the description, explain the principles ofthe invention. In the drawings,

FIG. 1 is a schematic block diagram of the implementation of anexemplary computer system for implementing methods consistent with thepresent invention.

FIG. 2 is a schematic diagram of an exemplary structure of a data objectin accordance with the principles of the inventive method.

FIG. 3 is a flow diagram of an exemplary implementation of the selectingmodule shown in FIG. 1.

FIG. 4 is a flow diagram of an exemplary method for implementation bythe writing module shown in FIG. 1.

FIG. 5 is a flow diagram of an exemplary method for implementation bythe deleting module shown in FIG. 1.

FIG. 6 is a flow chart of an exemplary method for implementation by theselection and writing module shown in FIG. 1.

FIG. 7 is a flow chart of an exemplary method to demonstrate how anysoftware application may use the concept of the P and T-locks.

FIG. 8 is a flow chart of an exemplary method to demonstrate how anysoftware application may use the concept of the P and T-locks, includinga conditional deletion of a P-lock.

FIG. 9 is a flow chart for an exemplary method for implementation by asoftware module through which the locks can be deleted.

DETAILED DESCRIPTION

Computer systems and programs are closely related. As used hereinafter,phrases, such as “the computer provides” and “the program provides orperforms specific actions,” and “a user performs a specific action” areconvenient abbreviations to express actions by a computer system that iscontrolled by a program or to express that the program or program moduleis designed to enable the computer system to perform the specific actionor the enable a user to perform the specific action by means of acomputer system.

Reference will now be made in detail to the principles of the inventionby explaining the invention on the basis of an archiving process,examples of which are illustrated in the accompanying drawings.Examples, mentioned therein, are intended to explain the invention andnot to limit the invention in any kind.

Within the concept of this description, the terms used shall have theirusual meaning in the context of the field of data processing unlessdefined otherwise in the following section:

A computer system can be a stand alone computer such as a PC or a laptopor a series of computers connected as a network, e.g. a network within acompany, or a series of computers connected via the internet. A dataobject to be archived can be any kind or type of data, e.g. numerical ortextual data, image data, meta data, irrespective whether the data areimplemented as whole files or parts of files or fields in tables,irrespective whether they are stored in volatile memory or nonvolatilememory. As an example, data objects according to the present inventioncan be implemented as one or more fields of one or more tables,particularly of tables of a relational data base system, or as objectsin an object orientated programming language.

The term ERP software shall be considerer to comprise any softwareapplication that supports the business processes of an enterprise.

A storage location is volatile or nonvolatile storage means accessibleby the computer system. It can be any kind of computer storage meansknown to one of ordinary skill, e.g. RAM, magnetical or optical storage,such as floppy disk, hard disk, MO-Disk, CD-ROM, CD RW, DVD ROM, DVD RW,etc. The first and second storage location can be identical. In thiscase, the archived data objects have to be stored at a place differentto the place of the original data objects to be archived. The secondstorage location can also be implemented as a file, located anywhere inthe accessible nonvolatile storage means. Such file is subsequentlyreferred to as archive file.

An identifier (ID) is a type of data, which allows an unambiguousidentification of the data object to be archived. It can be implemented,for example, as a number or a combination of alphanumerical charactersor as a characteristic part of the data object to be archived. It isclear from that definition that a data object can have a wide variety ofIDs. A lock object is a data object, in which the identifiers arestored. It can be implemented, e.g., as a file on a storage means or asa data array in computer memory. A first lock object is storedadvantageously in a nonvolatile storage means and a second lock objectis stored in volatile and/or nonvolatile storage means.

The assignment of the second storage location to an ID can beimplemented by a table, in which one field of a line contains the ID andanother field of that line contains a link to the second storagelocation, e.g. a file name. This table can be stored as a file on anonvolatile storage means.

FIG. 1 is a schematic block diagram of an exemplary implementation of acomputer system. FIG. 1 shows a computer system 101 comprising acomputer 103 having a CPU 105, a working storage 112, in which an ERPsoftware 111 is stored for processing by CPU 105. ERP software 111comprises program modules 106, 109, 110 for carrying out the inventivedata archiving process. Computer system 101 further comprises inputmeans 113, output means 112 for interaction with a user, and generalinput/output means 104, including a net connection 114, for sending andreceiving data. A plurality of computer systems 101 can be connected viathe net connection 114 in the form of a network 113. In this case, thenetwork computers 113 can be used as further input/output means,including as further storage locations. Computer system 103 furthercomprises a first storage means 107, in which data to be archived andthe lock object are stored, and a second storage means 108, in which thearchived data are stored.

In case the program modules 106, 109, 110 are processed by CPU 105 inorder to carry out the inventive process, one or more data objectsstored in the first storage means 107 are selected by selection module110. Selection module 110 assigns an ID to each of the selected dataobjects and stores the ID in the lock object at the storage location107. Writing module 106 reads the data objects and the lock object andstores such data objects, the ID of which are contained in the lockobject to the second storage location 108. Additionally, the secondstorage location 108 is assigned to the respective ID of the data objectin the lock object. Deleting module 109 then reads the archived dataobjects in the second storage location 108 and deletes the data objects,which it could successfully read from the original set of data objectsin the first storage location 107. After deleting a specific dataobject, to which an ID was assigned, that ID is deleted from the lockobject.

In an alternative embodiment, the lock object may be created by theselection module and not by the writing module.

In a second implementation of the invention, a data object to bearchived may comprise of one or more fields of one or more tables, andthe ID of the respective object may comprise of one or more key fieldsof that data object. This can best be seen from FIG. 2. In thisinstance, various sets of data objects are created in the form oftwo-dimensional data arrays, i.e., two tables (table 1 and table 2)having columns named field A to field X and field A to field Y,respectively, and a certain, unspecified number of lines. A field of thearray or table is defined by the name of the column and the respectiveline. Such a field can contain data to be archived. It can alternativelycontain a reference to a line of a further table. For example, in table1 field X in line 2 contains a reference to line 3 in table 2. A dataobject to be archived comprises of fields of one line of the respectivetable. If one of the fields contains a reference to a line of an othertable, fields of this referenced line belong to the data object as well.In the example in FIG. 2, a data object to be archived comprises thefields of line 2 in table 1 and fields of line 3 in table 2.

An ID of such a data object can be implemented by the content of one ormore so-called key fields, if the combination of these key fields isunique within the respective table. In the example, the fields of “heldA” and “field B” can be used as key fields for table 1, whereas field Aalone is key field in table 2. Within this example, assigning an ID tothe data object means to use the content of the fields of columns fieldA and B of the respective lines as the ID for that particular line. Inline with this assignment, the IDs for the data object to be archivedare stored as a first type ID in a first type lock object namedpermanent lock object in FIG. 2 and as a second type ID in a second typelock object named transactional lock object. The permanent lock objectmay be implemented as a table having two columns, the first of whichcontains the first type ID 1. The second type ID, ID 2, may beimplemented as a one-dimensional data array stored in the working memoryof the computer system. However, it can be implemented as a file on anonvolatile storage means, too. The first type ID, ID 1, is deletedafter the selected data object has been deleted according to theinventive process, and the second type ID, ID 2, may be deletedimmediately after. Alternatively, type ID 1 IDs can be deleted after allthe selected data objects have been deleted. As can be seen, both IDtypes have identical content, the ID of the respective lines of the datato be archived. However, this is not a necessary condition. It can beseen from the fact that the ID 2 of line BB is deleted, that this linehas already been archived, whereas line BC has not yet been stored tothe archive file. The two types can also be stored together in one lockobject. The permanent lock objects further contain a column by which afilename may be assigned to the ID of the data object, i.e. that dataobject to be archived. In the example, line 1 is archived in a filenamed 001, lines 2 and 3 in file 002, and line 4 in file 003.

The selection of the data object can be implemented by an automaticprocedure, such as by a simple query, that returns all lines having acertain field that satisfies a certain condition. For example, theprocedure could return all lines in which the content of a date fieldpre-dates or post-dates a certain deadline. Selection can also beimplemented by a user to whom a selection table is presented via agraphical user interface.

A further embodiment may comprise storing the ID in a second lock objectimmediately after assigning at least one identifier (ID) of at least onetype for the respective data object. Alternatively, the second type ofID of the selected data object is stored before storing the data objectassigned to that ID is started.

A further embodiment may comprise storing the IDs of the first type ofall selected data objects before storing the data object at the secondstorage location.

In a further embodiment, the invention may comprise checking whether anID for that data object has been stored in a lock object, and if the IDhas been stored, not storing the data object at the second location andassigning the second storage location to the ID in the lock object forthat data object.

Additionally, the invention may comprise checking whether the dataobject is contained in the second storage location, and if the dataobject is contained, not storing the data object, the ID of which iscontained in the lock object, at the second location and assigning thesecond storage location to the ID in the lock object for that dataobject.

Another embodiment may comprise checking by querying a lock object.

Another embodiment may comprise checking whether the data objectassigned to the respective ID has been completely stored in the secondlocation and, if the data object has not been stored, skipping the stepof deleting the data object from the first storage location and the stepof deleting the ID from the lock object after the respective data objectassigned to that ID has been deleted for that data object and deletingthe ID from the lock object.

Embodiments of the invention are now described in more detail withreference to FIGS. 3 to 5, which are schematic flow diagrams ofexemplary methods that may be implemented by the selecting, writing anddeleting modules, respectively, as shown in FIG. 1. Within the contextof this description, and particularly with respect to FIGS. 3 to 9, afirst type ID is called a P-lock (permanent) and a second type ID iscalled a T-lock (transactional). Therefore, setting a P or T-lock for aselected object means to store an ID of that object in a respective lockobject. The term “permanent” results for the property of the P-lock ofexisting permanently, as long as the data object is not yet deleted fromits original storage location. The term “transactional” results from theproperty of the T-lock of existing only as long as a specific action(e.g. checking of archiveability) is performed on a selected data objector, in other words, of being deleted after the respective action hasbeen performed.

In the exemplary flow chart of the selecting module in FIG. 3, a dataobject is selected in a first step 301. Subsequently, a T-lock is set onthis object in step 302. If the T-lock was successfully set (step 303),that is, if it did not yet exist, it is checked in step 304 whether aP-lock already exists in the selected data object. If not, the next dataobject is selected in step 309. The selling of the T-lock (step 302) andthe check (step 303), whether it is successfully, set can advantageouslybe implemented as one “atomic” step. This means that both steps can beexecuted essentially at the same time or, in other words, the time gapbetween both can be essentially zero.

Both checks (steps 303 and 304) can also be implemented by querying therespective lock objects. If a P-lock exists, the T-lock is deleted (step308) and the next data object is selected (step 309). If no P-lockexists, it is checked in steps 305 and 306 whether the data object isarchiveable. Such checking comprises a test of whether the data in thedata object is readable, complete, or not fraught with obvious failuresetc. If the test is successful, a P-lock is set on that data object instep 307, whereby no archive file is assigned to the data object at thatpoint. Then the T-lock is deleted (step 308) and the next data object isselected (step 309).

In the exemplary flow chart of the writing module in FIG. 4, a dataobject is selected in a first step 401. Subsequently, a T-lock is set onthis object in step 402. If the T-lock was successfully set (step 403),it is checked in step 404 whether a P-lock already exists in theselected data object, whereby no file must be assigned to that dataobject at that point of the process. If the condition is not fulfilled,the T-lock is deleted in step 407, and the next data object is selectedin step 408. If a P-lock exists, the data object is stored in an archivefile in step 405 and the archive file is assigned to the data object instep 406, e.g., by adding the file name to the lock object as shown inFIG. 2. Subsequently, the T-lock is deleted (step 407), and the nextdata object is selected (step 408).

In the exemplary flow chart of the deleting module in FIG. 5, a dataobject that has already been archived is selected (step 501). This canbe implemented by checking the archive files. If a data object has beenselected and successfully read from the archive file, that data objectis deleted from the original storage location (step 502), the P-lock isdeleted (step 503), and the next data object is selected (step 504).

In the exemplary flow chart of a further exemplary implementation inFIG. 6, the selecting module and writing module described above arecombined to one module. Accordingly, a data object is selected in afirst step 601. Subsequently, a T-lock is set on this object in step602. If the T-lock was successfully set (step 603), it is checked instep 604 whether a P-lock already exists in the selected data object. Ifthe T-lock could not be set successfully, the next data object isselected (step 610). If a P-lock exists on that object, the T-lock isdeleted (step 609) and the next data object is selected (step 610). Ifno P-lock exists on that object, it is checked in step 605 whether thedata object is archiveable. If this check fails (step 606), the T-lockis deleted (step 609), and the next data object is selected (step 610).If the check is positive, the data object is stored (step 605) in anarchive file, a P-lock is set (step 608) with the archive file assigned,the T-lock is deleted (step 609), and the next data object is selected(step 610).

FIG. 7 shows a flow chart of an exemplary method to demonstrate how anysoftware application can use the concept of the P and T-locks to ensurethat the measures, that the software application is going to apply onthe data object do not influence the archiving process. A softwareapplication that is programmed to have a read and/or write access todata objects, which can be subject of an archiving process as described,may comprise the following steps as shown in FIG. 7. In a first step701, the data object is selected. Then a T-lock is set in step 702 onthat object by the application. If the T-lock is successfully set (step703), it is checked in step 704, whether a P-lock exists on that object;otherwise the application terminates in step 707. If a P-lock exists onthat object (step 704), the T-lock is deleted (step 706), and theapplication terminates (step 707). If no P-lock exists, i.e., the dataobject is not subject to an archiving process, the application can haveread/write access to the data object in a working step 705.Subsequently, the application deletes the T-lock (step 706) andterminates (step 707).

FIG. 8 is a flow chart of another exemplary method to demonstrate howany software application may use the concept of the P and T-locks,including a conditional deletion of a P-lock. In a first step 801, thedata object is selected. Then, a T-lock is set on that object by theapplication (step 802). If the T-lock is successfully set (step 803), itis checked (step 804) whether a P-lock exists on that object; otherwisethe application terminates (step 809). If no P-lock exists (step 804),i.e., the data object is not subject to an archiving process, theapplication can have read/write access to the data object in workingstep 807. Subsequently, the application deletes the T-lock (step 808)and terminates (step 809). If a P-lock exists (step 804), it is checked(step 805) whether a file is assigned to it. If a file is assigned, theapplication deletes the T-lock (step 808) and terminates (step 809). Ifno file is assigned, the P-lock is deleted (step 806), and theapplication can have read/write access to the data object (step 807).Subsequently, the application deletes the T-lock (step 808) andterminates (step 809).

This procedure is particularly useful, in that data objects, which arenot yet stored in an archive file, can be still altered. Consequently,they can be archived only at the next archive run.

FIG. 9 is a flow chart of an exemplary method for implementation by asoftware module through which the locks set by the modules describedabove can be deleted. This can be useful in cases in which no archivefiles are assigned to P-locks or in which P-locks have been deleted fora user. Therein, a P-lock is nothing else than a data object and can betreated in the same way as described above. In a first step 901, aP-lock is selected. Then, a T-lock is set to the P-lock in (step 902).If the T-lock is successfully set (step 903), it is checked (step 904),whether the P-lock has a file assigned. If the T-lock is not setsuccessfully, the module terminates (step 907). If the selected P-lockhas no file assigned (step 904), the P-lock is deleted (step 905). Thenthe T-lock is deleted (step 906) and the module terminates (step 907).Alternative to the termination step 907, a next P-lock can be selected.

Modifications and adaptations of the present invention will be apparentto those skilled in the art from consideration of the specification andpractice of the invention disclosed herein. The foregoing description ofan implementation of the invention has been presented for purposes ofillustration and description. It is not exhaustive and does not limitthe invention to the precise form disclosed. Modifications andvariations are possible in light of the above teachings or can beacquired from the practicing of the invention. For example, thedescribed implementation includes software, but systems and methodsconsistent with the present invention can be implemented as acombination of hardware and software or in hardware alone. Additionally,although aspects of the present invention are described for being storedin memory, one skilled in the art will appreciate that these aspects canalso be stored on other types of computer-readable media, such assecondary storage devices, for example, hard disks, floppy disks, orCD-ROM; the Internet or other propagation medium; or other forms of RAMor ROM. It is intended that the specification and examples be consideredas exemplary only, with a true scope and spirit of the invention beingindicated by the following claims.

Computer programs based on the written description and flow charts ofthis invention are within the skill of an experienced developer. Thevarious programs or program modules can be created using any of thetechniques known to one skilled in the art or can be designed inconnection with existing software. For example, programs or programmodules can be designed in or by means of ® Java, C++, HTML, XML, orHTML with included Java applets or in SAP R/3 or ABAP.

1. A method for moving data objects in a computer system from a firststorage location to a second storage location of a hardware memorydevice, the method comprising: selecting a data object stored in thefirst storage location, the data object being assigned to an identifier(ID); determining, using a processor, whether another process isattempting to perform a transaction with the data object by queryingwhether the ID is stored in a transactional type lock object; upondetermining that another process is not attempting to perform atransaction with the data object, storing the ID in the transactionaltype lock object; determining, using the processor, whether anotherprocess is moving the data object to a new storage location by queryingwhether the ID is stored in a permanent type lock object; upondetermining that another process is not moving the data object to a newstorage location, storing the ID in the permanent type lock object;determining whether the ID is stored successfully in the permanent typelock object, and upon a successful storage, deleting the ID from thetransactional type lock object; storing the data object at the secondstorage location; assigning the second storage location to the ID in thepermanent type lock object; deleting the data object from the firststorage location; and deleting the ID from the permanent type lockobject, after the data object has been deleted from the first storagelocation.
 2. The method of claim 1, wherein the data object comprisesone or more fields of one or more tables, and wherein the ID comprisesone or more key fields of the one or more tables.
 3. The method of claim1, wherein the data object is stored in a file and wherein an assignmentof the ID to the file or a name of the file is stored in the permanenttype lock object.
 4. The method of claim 1, wherein storing the ID inthe permanent type lock object comprises storing IDs of other dataobjects in the permanent type lock object before storing the data objectat the second storage location.
 5. The method of claim 1, furthercomprising: checking whether the data object is stored in the secondstorage location and if the data object is stored in the second storagelocation, skipping storing the data object at the second storagelocation.
 6. The method of claim 5, wherein checking whether the dataobject is stored in the second storage location comprises queryingwhether the ID is stored in at least one of the transactional type lockobject and the permanent type lock object.
 7. The method of claim 1,further comprising: checking whether the data object has beensuccessfully stored in the second storage location, and if the dataobject has not been successfully stored in the second storage location,skipping deleting the data object from the first storage location andskipping deleting the ID from the permanent type lock object.
 8. Themethod of claim 1, for use in an enterprise resource planning software.9. A computer system for processing data, the computer systemcomprising: memory means for storing program instructions; input meansfor entering the data; storage means for storing the data; a processorresponsive to the program instructions, wherein the program instructionscomprise program code means for performing a method for moving dataobjects in the computer system from a first storage location to a secondstorage location of the storage means, the method comprising: selectinga data object stored in the first storage location, the data objectbeing assigned to an identifier (ID); determining whether anotherprocess is attempting to perform a transaction with the data object byquerying whether the ID is stored in a transactional type lock object;upon determining that another process is not attempting to perform atransaction with the data object, storing the ID in the transactionaltype lock object; determining whether another process is moving the dataobject to a new storage location by querying whether the ID is stored ina permanent type lock object; upon determining that another process isnot moving the data object to a new storage location, storing the ID inthe permanent type lock object; determining whether the ID is storedsuccessfully in the permanent type lock object, and upon a successfulstorage, deleting the ID from the transactional type lock object;storing the data object at the second storage location; assigning thesecond storage location to the ID in the permanent type lock object;deleting the data object from the first storage location; and deletingthe ID from the permanent type lock object, after the data object hasbeen deleted from the first storage location.
 10. A computer readablestorage medium comprising instructions for performing a method formoving data objects in a computer system from a first storage locationto a second storage location of a hardware storage device, the methodcomprising: selecting a data object stored in the first storagelocation, the data object being assigned to an identifier (ID);determining, using a processor, whether another process is attempting toperform a transaction with the data object by querying whether the ID isstored in a transactional type lock object; upon determining thatanother process is not attempting to perform a transaction with the dataobject, storing the ID in the transactional type lock object;determining, using the processor, whether another process is moving thedata object to a new storage location by querying whether the ID isstored in a permanent type lock object; upon determining that anotherprocess is not moving the data object to a new storage location, storingthe ID in the permanent type lock object; determining whether the ID isstored successfully in the permanent type lock object, and upon asuccessful storage, deleting the ID from the transactional type lockobject; storing the data object at the second storage location;assigning the second storage location to the ID in the permanent typelock object; deleting the data object from the first storage location;and deleting the ID from the permanent type lock object, after the dataobject has been deleted from the first storage location.
 11. Thecomputer readable storage medium of claim 10, wherein the data objectcomprises one or more fields of one or more tables, and wherein the IDcomprises one or more key fields of the one or more tables.
 12. Thecomputer readable storage medium of claim 10, wherein the data object isstored in a file and wherein an assignment of the ID to the file or aname of the file is stored in the permanent type lock object.
 13. Thecomputer readable storage medium of claim 10, wherein storing the ID inthe permanent type lock object comprises storing IDs of other dataobjects in the permanent type lock object before storing the data objectat the second storage location.
 14. The computer readable storage mediumof claim 10, wherein the method further comprises: checking whether thedata object is stored in the second storage location and if the dataobject is stored in the second storage location, skipping storing thedata object at the second storage location.
 15. The computer readablestorage medium of claim 14, wherein checking whether the data object isstored in the second storage location comprises querying whether the IDis stored in at least one of the transactional type lock object and thepermanent type lock object.
 16. The computer readable storage medium ofclaim 10, wherein the method further comprises: checking whether thedata object has been successfully stored in the second storage location,and if the data object has not been successfully stored in the secondstorage location, skipping deleting the data object from the firststorage location and skipping deleting the ID from the permanent typelock object.
 17. A computer system for processing data, the computersystem comprising: a processor executing program instructions; means forselecting a data object stored in a the first storage location of ahardware memory device, the data object being assigned to an identifier(ID); means for determining whether another process is attempting toperform a transaction with the data object by querying whether the ID isstored in a transactional type lock object; means for storing the ID inthe transactional type lock object when it is determined that anotherprocess is not attempting to perform a transaction with the data object;means for determining whether another process is moving the data objectto a new storage location by querying whether the ID is stored in apermanent type lock; means for storing the ID in the permanent type lockobject, when it is determined that another process is not moving thedata object to a new storage location; means for determining whether theID is stored successfully in the permanent type lock object, and upon asuccessful storage, deleting the ID from the transactional type lockobject; means for storing the data object at the a second storagelocation of the hardware memory device; means for assigning the secondstorage location to the ID in the permanent type lock object; means fordeleting the data object from the first storage location; and means fordeleting the ID from the permanent type lock object, after the dataobject has been deleted from the first storage location.
 18. Thecomputer system of claim 17, wherein the data object comprises one ormore fields of one or more tables, and wherein the ID comprises one ormore key fields of the one or more tables.
 19. The computer system ofclaim 17, further comprising: means for storing the data object in afile; and means for storing an assignment of the ID to the file or aname of the file in the permanent type lock object.
 20. The computersystem of claim 17, wherein the means for storing the ID in thepermanent type lock object comprises means for storing IDs of other dataobjects in the permanent type lock object before storing the data objectat the second storage location.
 21. The computer system of claim 17,further comprising: means for checking whether the data object is storedin the second storage location and if the data object is stored in thesecond storage location, skipping storing the data object at the secondstorage location.
 22. The computer system of claim 21, wherein the meansfor checking whether the data object is stored in the second storagelocation comprises means for querying whether the ID is stored in atleast one of the transactional type lock object and the permanent typelock object.
 23. The computer system of claim 17, further comprising:means for checking whether the data object has been successfully storedin the second storage location, and if the data object has not beensuccessfully stored in the second storage location, skipping deletingthe data object from the first storage location and skipping deletingthe ID from the permanent type lock object.